If you read your news from an NNTP server that's far away, the network latencies may make reading articles a chore. You have to wait for a while after pressing n to go to the next article before the article appears. Why can't Gnus just go ahead and fetch the article while you are reading the previous one? Why not, indeed.
First, some caveats. There are some pitfalls to using asynchronous article fetching, especially the way Gnus does it.
Let's say you are reading article 1, which is short, and article 2 is quite long, and you are not interested in reading that. Gnus does not know this, so it goes ahead and fetches article 2. You decide to read article 3, but since Gnus is in the process of fetching article 2, the connection is blocked.
To avoid these situations, Gnus will open two (count 'em two) connections to the server. Some people may think this isn't a very nice thing to do, but I don't see any real alternatives. Setting up that extra connection takes some time, so Gnus startup will be slower.
Gnus will fetch more articles than you will read. This will mean that the link between your machine and the NNTP server will become more loaded than if you didn't use article pre-fetch. The server itself will also become more loaded—both with the extra article requests, and the extra connection.
Ok, so now you know that you shouldn't really use this thing... unless you really want to.
Here's how: Set
gnus-asynchronous to t. The rest should
happen automatically.
You can
control how many articles are to be pre-fetched by setting
gnus-use-article-prefetch. This is 30 by default,
which means that when you read an article in the group, the back
end will pre-fetch the next 30 articles. If this variable is
t, the back end will pre-fetch all the articles it
can without bound. If it is nil, no pre-fetching
will be done.
There are
probably some articles that you don't want to
pre-fetch—read articles, for instance. The
gnus-async-prefetch-article-p variable controls
whether an article is to be pre-fetched. This function should
return non-nil when the article in question is to be
pre-fetched. The default is gnus-async-unread-p,
which returns nil on read articles. The function is
called with an article data structure as the only parameter.
If, for instance, you wish to pre-fetch only unread articles shorter than 100 lines, you could say something like:
(defun my-async-short-unread-p (data)
"Return non-nil for short, unread articles."
(and (gnus-data-unread-p data)
(< (mail-header-lines (gnus-data-header data))
100)))
(setq gnus-async-prefetch-article-p 'my-async-short-unread-p)
These functions will be called many, many times, so they should preferably be short and sweet to avoid slowing down Gnus too much. It's probably a good idea to byte-compile things like this.
After
an article has been prefetched, this
gnus-async-post-fetch-function will be called. The
buffer will be narrowed to the region of the article that was
fetched. A useful value would be
gnus-html-prefetch-images, which will prefetch and
store images referenced in the article, so that you don't have to
wait for them to be fetched when you read the article. This is
useful for HTML messages that have external
images.
Articles have to be removed from the asynch buffer sooner or
later. The gnus-prefetched-article-deletion-strategy
says when to remove articles. This is a list that may contain the
following elements:
readexitThe default value is (read exit).